在業界打滾數年的產品經理或工程師，一定有遇過這樣的經驗:

老闆不知道哪裡來的靈光乍現，很興奮地跑來跟你分享一個他剛剛想到的點子，老闆希望這個想法可以快速地被實現，以最高優先級進入開發與上線。

在日本，這樣的故事被戲稱為隕石式開發(メテオフォール型開発, 中文版本可以參考ITHome的這篇文章)，形容這些如「天神般存在的老闆」突如其來地對產品進行改變，就像隕石一樣直接砸了下來破壞既定的計畫，要團隊重新開始或是變更工作內容，小的隕石可能只會破壞目前的計畫，大的隕石則可能破壞團隊之前的努力，讓做到一半的成品直接作廢。

為什麼會有隕石?

資訊焦慮

當老闆對自己的產品現況或是未來感到焦慮時，很容易發生隕石。老闆可能昨天參加了某個應酬聚會，跟朋友或投資人聊到某個市場很有未來，或是在社群媒體上看到某篇文章介紹了新的商業模式，在網站上看到類似產品推出了新的功能，或者回家爸爸跟他分享他在新聞上看到了什麼新玩意。老闆每天接觸這麼多新東西很容易陷入資訊焦慮，感覺產業速度進展很快，但是目前自己的產品越來越慢(落後)，於是就會今天想做A明天又想做B。

風險承受度

對老闆來說，創業開公司每天在大撒幣，看著大把大把的花錢流出口袋，因此一旦心裡有新的想法就希望能快點看到結果，很容易一頭熱地要在有限的時間內看到東西快點做出來，於是現在正在做的所有事情會被老闆直接忘光。

外部環境變動

有時候隕石跟老闆不見得有關，而是受到企業外部的環境突然變動，為了適應這個改變必須即時做出的調整。這種需求來的很臨時也很棘手。例如: 客服突然收到客戶來信說某個功能導致他造成身心傷害決定要提告我們，或是原本APP內的收費方式突然被App Store禁止，將直接影響到收入，或是歐洲來個GDPR、中國伺服器必須在地化等等。

Ref: https://eiki.hatenablog.jp/entry/meteo_fall

面對隕石開發的密技

面對外部環境變動的隕石比較簡單，主要是衡量緊急與重要程度決定事情的優先順序就好。如果遇到來自老闆突然掉下來的隕石也不要慌張，讓PM猴子來分享一個重要的技巧:

"搞定老闆的 P̶U̶S̶S̶Y̶ PUSSI ，就搞定了天上掉下來的隕石"
-PM猴子

通常一個隕石的形式是一個單純的功能，來自於老闆的一兩句話，沒有足夠的資訊，但其實這個想法背後隱含了五個重要的假設，PM猴子將之命名為PUSSI。產品經理需要搞清楚背後的假設，才能有效的面對它，接受它，處理它，放下它。

• P - 問題（Problem）：這個想法背後要解決客戶/公司的什麼問題?這個問題在老闆心中有多嚴重?對客戶又有多嚴重? 有時候老闆想解決的不見得都是客戶的問題，也有可能是想解決公司的某些問題。
• U - 使用者（User）：這個功能在解決哪些人的問題? 這個功能的目標使用者(Target user)是誰? 受益者又會是誰? 這些使用者佔有多少比例?
• S - 情境（Scenario）：在什麼樣的情境下這個問題會發生，發生的頻率有多高? 是每天/每周/每月/每半年還是更久? 隨著發生頻率的不同，也會影響到緊急程度
• S - 解法（Solution）：這個功能為什麼能解決現在的問題?現在的替代功能是什麼有何缺點與不足之處? 或是有沒有其他更好的解決辦法
• I- 影響（Impact）：這個功能實現後，老闆認為可以為公司/產品帶來什麼影響? 預期帶來的正向影響會有多大? 會不會有潛在的負面影響?

當我們把以上的PUSSI思考過一遍之後，就可以針對不同的情境採取不同策略來面對隕石需求

應對策略

問題(P)、使用者(U)、情境假設(S)搞不清楚

如果跟老闆詢問或是討論後發現，問題(P)、使用者(U)、情境假設(S)都還不夠清楚，或是可以說出個所以然，但是對於P,U,S的假設信心很低，那通常代表失敗的程度頗高。這時候可以先詢問老闆，是否可以在正式實作這個功能之前，先花一點時間來驗證問題的嚴重性、使用者是誰/數量多少、問題發生頻率等等，以確保投入資源在這次的改動是正確的。可以告訴老闆我們可以用一些簡單快速驗證方式例如蒐集現在的產品使用者行為(user behavior log)，或是發問卷，進行使用者訪談來釐清這些假設，如果真的問題很嚴重、使用者存在且夠多、發生頻率也很頻繁再以最高優先級插件來實作(驗證同時也可以先把目前工程師手上的工作進行收尾)

影響(I) 不清楚

如果已經清楚問題 P 是嚴重的，使用者 U 與情境 S 是存在的，但是對於影響還搞不清楚，這時候就要跟老闆一起思考ROI，並且提供幾個選擇讓老闆知道如果在I不清楚的情況下就開始停下手邊所有事情改作隕石需求，潛在的成本是多少。透過ROI的方式讓老闆可以重新衡量事情的緊急與重要程度。根據PM猴子的經驗，很多時候當老闆從一股腦的熱情中冷靜下來，回歸理性就會有不同的想法。

問題(P)、使用者(U)、情境假設(S)、影響(I)都清楚

在這樣的情況下，可以思考老闆所提供的功能(Solution)是否已是最佳解法，有沒有對公司/使用者更好的解決方案，可以列出一些選擇跟各自的優缺點，再做決定前與老闆討論不同的解決方案，確保我們的功能可以長期對使用者有益

PUSSI的每個假設都很清楚

在這些都清楚的情況下，通常代表老闆對於這件事已經有認真思考過，於是乎就是確認是不是真的有這麼急迫，一定要以隕石的方式排掉現在正在做的事情。一個常見的方式是套用公司既有的排序優先級框架(如果有的話，可以參考我寫過的討論優先級的系列文章) 重新將目前的功能進行排序優先級，再以最新的排序結果給老闆一個完整的資訊，跟老闆說明哪些事情可能更重要，需要優先完成。

老闆執意要做的話

好啦，看完上述方法一定有人會說沒用啦，老闆就像蒼蠅看到大便一樣堅持，執意要立刻去做的話，那身為產品經理這個時候就不要再花時間進行驗證了，因為老闆就是想要看到產品上線，所以一旦開始進入開發階段，就不需要花時間同時進行驗證，因為不論最終驗證結果如何，產品都已經做出來了，所有驗證過程變成只是浪費時間而已。不過別忘了產品是上線之後才開始，如果希望打造出對使用者真的有幫助的產品，在實作功能時應該同時思考怎麼樣去衡量產品是否成功，設定對應指標，例如:可否進行A/B測試來檢驗成效、留存率、轉換率等等，並且在開發前就先將需要收集的使用者資料寫入開發規格中，這樣等到產品上線一段時間後，就可以衡量成效看看是否成功。當然可能老闆眼光精準，一開始就是對的，那真的超棒，但如果效果不如預期，還是可以持續地迭代改進，逐漸將原本的隕石優化成對使用者／公司真正有幫助的功能。

隕石搞得跟流星雨一樣

如果隕石真的很常發生，而且每次都沒有討論的空間的話，那改變老闆不如改變團隊的做事方式。可以考慮在每次的開發過程中都先預留部分的緩衝。例如直接成立一個專門負責臨時需求的團隊或是在每次的開發時程中預留一定比例的時間來處理這些插件跟隕石。

身為產品經理，面對很多的隕石，就像F4唱的: 陪你（工程師）去看流星雨落在這產品上，讓你（工程師）的累落在我肩膀
-PM猴子

Ref: 摩信網

結語

在大部分的產品開發工作中，一定多少會遇到隕石或是臨時緊急需求，與其一味的反對與抱怨，不如重新思考發生的原因以及大家的長遠目標是否一致。PM猴子認為在工作上大家都希望能幫助到使用者並使產品成功，身為產品經理，我們都應該想辦法在商業數據和用戶研究的基礎上做出最佳決策，不管是功能開發前或是開發後，讓我們一起面對它、接受它、處理它、放下它。

Ref: 法鼓山